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ABSTRACT:  The  JIAWG  Input/Output  System  (JiOS) 
provides  the  software/hardware  interface  for 
Built-In-Test  and  I/O  provided  via  the  Pi-Bus  and 
TM-Bus  for  the  JiAWG  i 6— b i t  Common  Modules.  This 
paper  describes  the  need  for  JiOS,  the 
functionality  of  the  JIOS,  concerns  related  to 
the  use  of  the  JIOS,  and  a  planned  JiOS 
demonstrat ion. 

1 . 0  Overview 

The  Joint  Integrated  Avionics  Working  Group 
(JiAWG)  is  a  Congressional ly  mandated  tri-service 
organization  founded  to  establish  design  standards 
and  specifications  for  the  three  service's  next 
generation  aircraft.  A  subset  of  these  documents 
is  concerned  with  the  development  of 
interchangeable  hardware  modules.  Two  hardware 
modules  are  considered  interchangeable  if 

*  the  two  modules  will  work  electrically 
to  specifications  within  the  same  slot 

*  operational  software  will  execute  on  both 
modules  without  modification. 

These  common  modules  are  to  be  usable  by  all  three 
services  and  are  to  be  built  under  the  philosophy 
of  form-f tt-funct ion-and- interface  (as  compared 
to  bui 1 t-to-pr tnt ) .  The  JiAWG  produced  documents 


will  be  referenced  contractually  in  the  next 
generation  aircraft  procurements. 

Two  JiAWG  documents  are  responsible  for 
defining  the  standard  1 6— bl t  processing  module. 
Specifically,  these  documents  are  the  16-Bit 
Common  Avionics  Processor  (CAP- 16)  specification 
and  the  Common  Avionics  Processor  i 6-Bit 
Instruction  Set  Architecture  (ISA)  specification. 
Together,  these  documents  define  the  standard 
16-bit  processing  module  to  be  a  M1L-STD-I750A, 
Notice  1  Instruction  Set  Architecture  (ISA), 
together  with  the  module  hardware  and  software 
interfaces  and  functions.  Two  of  the  most 
difficult  issues  to  solve  regarding  the  iSA  have 
been  the  input /Output  (i/O)  implementation  and 
a  standard  approach  to  module  level  Built-in-Test 
(BIT). 

The  type  of  1/0  required  for  CAP- 16  is 
associated  with  the  backplane  bus  hardware.  The 
primary  intermodule  communication  channel  is  a 
dual  redundant,  single  controller,  Very  High  Speed 
Integrated  Circuit  (VHSiC),  Phase  II,  Pi -Bus,  as 
specified  in  the  JiAWG  Pi -Bus  specification.  A 
dual  VHSIC  Test  and  Maintenance  (TM)  Bus 
interface,  as  defined  by  the  JiAWG  TM-Bus 


Table  1.  Differences  in  CAP-16  Vendor  Designs 


ITEM 


DIFFERENCES 


Software  Interface  to 
PI -Bus 


-  Different  X10  assignments 

-  Difference  in  Pi -Bus  data  structures 

-  Difference  in  interrupt  structure 

-  Even  though  there  is  much  common 
functionality,  there  are  some 
differences  in  functionality 


Software  interface  to 
TM-Bus 


-  Different  XiO  assignments 

-  Difference  in  TM-Bus  data  structures 

-  Major  differences  in  overall 
commands  and  functionality 

-  difference  in  interrupt  structure 


Software  Interface  to 
Bui  1 1-1 n-Test 


-  Different  BIT  reporting  methods, 
including  amount  of  and  format 
of  information  reported 

-  Difference  In  BIT  functionality 
supported  and  in  manner 

B 1 T  funct i ona 1 i ty  i n i t i ated 
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specification,  is  also  needed  to  provide 
Intermodule  support  for  fault  tolerance, 
testability,  and  diagnostics.  Finally,  a 
Built-In-Test  Interface  Is  required  to  provide 
software  access  to  the  module  diagnostic  hardware. 


Four  CAP- 1 6  vendors  support  next  generation 
aircraft  Demonstrat lon/Val ldatlon  and  Fuii  Scale 
Development  programs  of  the  three  services. 
However,  each  of  the  ongoing  programs  began  prior 
to  establishment  of  the  JIAWG.  As  a  consequence, 
the  great  flexibility  that  MIL-STD-I750  allows 
regarding  I/O  allowed  the  four  JiAWG  CAP- 1 6 
vendors'  designs  to  be  quite  different.  A  summary 
of  these  differences  is  presented  in  Table  I.  This 
Is  a  major  commonality  problem  that  required  an 
unconventional  solution,  the  JIAWG  input/Output 
System  (JIOS).  In  order  to  understand  the  problem 
more  fully,  though,  an  examination  of  the  f/0 
requirements  of  MIL-STD-I750A  is  needed. 

2.0  M IL-STD-I 750  INPUT/OUTPUT 

Within  the  M IL-STD-I 750A  Instruction  Set 
Architecture  all  I/O  is  required  to  occur  through 
execute  Input/Output  { X 1 0 )  instructions.  There  are 
three  types  of  XiO  instructions:  mandatory, 
optional,  and  user  defined.  The  user  defined  XIO 
Instructions  are  used  to  allow  MiL-STD-l 750A 
processors  to  interface  to  i/O  hardware  which  Is 
not  defined  in  MIL-STD-1750A.  These  user  defined 
XIO  instructions  are  associated  with  "spare" 
channel  codes.  The  standard  reserves  2 1 ♦ 1 40  read 
channel  codes  and  an  equal  number  of  write  codes 
for  user  defined  XI Os. 

Once  a  hardware  interface  controller,  such  as 
a  Pi-Bus  Interface  Unit  (PBIU)  is  defined,  XIOs 
can  be  defined  to  permit  communication  between  the 
processor  and  the  controller.  As  a  consequence, 
the  XIOs  reflect  the  underlying  bus  Interface 
logic,  especially  with  respect  to  register  and 
memory  control.  Thus,  different  I/O  hardware 
implementations  may  have  not  only  different  XIO 
mnemonics  and  channel  code  assignments,  but 
different  XIO  functions. 

Three  of  the  four  vendors  associated  with  the 
CAP- 1 6  directly  control  input/output  with  user 
defined  XIO  commands.  That  Is,  XIO  commands  are 
used  to  communicate  with  the  I/O  controller 
register  structure,  point  to  transfer  blocks  in 
memory,  and  update  channel  control  data  structures 
in  memory.  Unfortunately,  a  thorough  Investigation 
of  these  XiO  commands  showed  that,  wht ie  there 
is  some  commonality  in  overall  PBIU  functionality, 
there  is  almost  no  commonality  among  XiO 
implementations  in  the  designs.  This  Isa 
consequence  of  the  hardware  differences  among  the 
I/O  controllers.  Therefore,  it  became  clear  that 
either  one  particular  design  must  be  selected  or  a 
new  XIO  design  developed,  in  order  to  have  common 


CAP- 1 6  XIOs.  The  cost  and  schedule  impact  of  the 
redesigns  was  so  large  that  the  JIAWG  began  to 
Investigate  alternatives. 

The  fourth  JIAWG  vendor  uses  memory  mapped 
I/O.  This  tnvotves  providing  hardware  within  the 
memory  management  unit  which  controls  reads  and 
writes  to  dedicated  i/0  memory  locations. 
Unfortunately,  there  are  no  predefined 
MIL-STD-I750A  ISA  structures  which  lend  themselves 
easily  to  such  I/O.  As  a  consequence,  this 
implementation  has  no  XIO  commonality  with  the 
designs  of  the  other  CAP- 1 6  vendors  and,  as  such, 
selection  of  this  design  suffers  the  same 
drawbacks  as  selecting  one  of  the  three  other  XIO 
designs. 

The  CAP- 1 6  dilemma,  then  is  to  define  some 
common  ISA  mechanism  which  wl 1 i  not  render  all 
existing  designs  obsolete,  will  support  the 
form-f lt-funct ion-and- interface  common  moduie 
acquisition  approach,  yet  can  be  used  as  as  a 
baseline  to  grow  to  a  pure  hardware,  assembly 
ianguage  interface.  The  JIOS  concept  was 
formulated  to  answer  this  need. 

3.0  JIOS  STRUCTURE 

The  JIOS  Is  intended  to  be  a  generic  software 
interface  for  BIT  as  well  as  PI  and  TM  buses.  The 
hardware  and  software  which  comprise  the  JIOS  are 
required  to  be  an  Integral  part  of  the  module 
architecture  so  that  no  operational  software 
downloads  are  needed. 

The  JIOS  features  are  specified  by  the  JiAWG 
Input /Output  Bui  It- In-Test  Interface  Definition 
Specification  UOBiDS).  IOBIDS  contains  a  complete 
definition  of  the  user  Interface  Including 
functions  provided,  calling  sequences,  parameter 
type  definitions,  and  special  user  requirements. 
These  definitions  are  provided  as  an  Ada  package 
specification  with  no  package  body,  for  each 
functionai  area.  The  package  body  Is  not  provided 
since  this  would  be  vendor  specific  and,  as 
such,  following  Ada  package  body  visibility  rules, 
is  not  visible  to  operational  software  or  the 
Runtime  System  (RTS).  Linkage  conventions  are 
also  established  so  that  operational  software 
and  Runtime  Systems  can  be  linked  to  the  JIOS 
faci I i t i es . 

Figure  I  depicts  the  reiatlonship  between  the 
JIOS,  CAP- I 6  moduie  hardware,  and  operatlonai  and 
RTS  software.  The  JIOS  provides  a  software  layer 
which  interfaces  with  operational  software  or 
RTS.  This  layer  then  implements  the  desired 
functionality  using  a  combination  of  software  and 
cails  to  module  hardware. 

Four  I/O  designs  exist  upon  which  to  base  the 
JIOS  designs.  Hence,  the  development  of  the  IOBIDS 
has  been,  in  effect,  a  top-down  functional  design 
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OPERATIONAL  SW  AND  RTS 


I/O  AND  BIT 
ACCESSES 


O  1750A  UNDEFINED  XIOs, 
D  REGISTERS,  AND  DATA 
y  STRUCTURES: 

,  -PI-BUS  XIOs 
“  -PI-BUS  REGISTERS 
E  -PI-BUS  DATA  STRUCTURES 
-TM-BUS  XIOs 
..  -TM-BUS  REGISTERS 
n  -TM-BUS  DATA  STRUCTURES 

W  -••• 


(DIRECTLY  ACCESSABLE 
HARDWARE  FUNCTIONS 


XIOs,  REGISTERS,  AND 
DATA  STRUCTURES 
DEFINED  BY  1750A  STD: 

-TIMERS  A  AND  B  XIOs 
-1750A  STATUS  REGISTER 
-PAGE  REGISTER  DEFINITIONS 
-PAGE  REGISTER  XIOs 


Figure  1.  JiOS,  Hardware ,  and  Software  Relationships 


instead  of  more  traditional  XIO  definitions  which 
are  targeted  to  specific  hardware  controllers. 
However,  the  linkage  conventions  established  in 
I OB  I DS  are  intended  to  offer  a  natural  path  to  a 
compiete  hardware  impiementat ion.  it  is  noted, 
though,  that  if  there  are  to  be  no  modifications 
to  existing  operational  or  RTS  software,  then  a 
small  part  of  the  JiOS  wiii  a i ways  be  present  to 
provide  a  transiation  from  the  assembiy  ianguage 
subprogram  call  to  the  hardware/XiO  interface. 

The  linkage  conventions  wiii  be  used  to 
establish  vector  tables  and  other  data  structures 
needed  for  a  pure  hardware  impiementat ion.  The 
final  step  of  the  JiOS  definition,  then,  is  to 
define,  in  effect,  an  entirely  new  set  of  user 
defined  XIOs  which  can  be  implemented 
convent ionai I y.  The  flexibility  that  I  OB  I DS 
offers,  though,  allows  existing  designs  to  be 
compi iant  with  JIAWG  interface  standards  by 
providing  ISA  patches  for  non-comp  I iant  hardware. 

At  the  time  this  paper  was  written,  the 
Pi -Bus  and  BiT  portions  of  the  JiOS  were  defined 
in  the  i OB  IDS.  However,  the  JIAWG  TM-Bus  Backplane 
Specification  was  not  well-defined,  so  the 
TM-Bus  interface  wiii  not  be  described  in  this 
paper.  The  remainder  of  this  section  gives  an 
overview  of  the  BIT  and  PI -Bus  requirements  of 


the  JIOS  as  documented  in  the  I OB  IDS. 

3.)  BiT  Structure 

The  CAP-i6  BIT  implementations  are  as  diverse 
as  the  backplane  bus  designs,  and  deriving  cofmion 
functions  from  this  diversity  is  difficult. 
Therefore,  the  JIOS  provides  a  functionaiiy  simpie 
interface,  with  reiativeiy  uncomplicated  reporting 
mechanisms.  Only  memory  systems,  CPU,  and 
backplane  systems  are  inciuded  in  the  JIOS  BIT 
interface.  Other  vendor  unique  hardware  cannot 
invoked  from  the  JiOS. 

CAP- 1 6  systems  offer  power-up,  initiated,  and 
periodic  BIT.  The  JIOS  provides  an  interface  oniy 
for  periodic  BiT,  as  that  is  the  primary  resource 
needed  by  the  app  Meat  ion  software.  However,  a 
primitive  initiated  BIT  can  be  constructed  from 
the  application  software  using  JIOS  procedures. 
These  procedures  a  Mow  the  software  to  start 
and  stop  periodic  BiT,  recall  the  periodic  test 
resuits,  and  test  the  CPU,  memory,  or  backplane 
system  individual iy. 

Three  types  of  tests  can  be  called  through 
the  JIOS:  CPU,  memory,  and  backplane.  Each  of 
these  procedures  has  an  input  parameter  whose 
value  is  either  destructive  or  non-destructive, 
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which  allows  the  application  program  to  save  the 
current  data  or  context  prior  to  invocation.  Each 
procedure  can  be  called  individually,  thus 
providing  a  simple  initiated  BIT.  Periodic  BIT 
executes  all  three  types  of  tests  continuously. 
Results  from  periodic  BIT  can  be  sampled  by 
calling  the  procedure  ACCESSJ31T_STATUS_W0RDS. 

The  test  results  include  a  summary  word. 
Individual  words  for  the  separate  procedures,  and 
interfaces  to  the  M1L-STD-1750  Fault  Register  (FT) 
and  Memory  Fault  Status  Register  (MFSR).  The 
summary  word  simply  identifies  what  type  of 
hardware  failed,  such  as  the  CPU,  PI -Bus  A  or  B, 
discretes,  memory,  or  others.  The  individual 
words  for  the  procedures  offer  more  detail  as  to 
the  failure,  such  as  the  page  of  the  memory  which 
failed.  The  FT  and  MFSR  interfaces  are  needed 
because  the  spare  bits  allowed  by  Mll-STD-1750  for 
these  registers  have  been  implemented  differently 
by  the  various  vendors. 

The  J10S  BIT  package  is  Intended  to  provide 
common  test  functions  for  access  by  application 
software.  Given  the  diversity  of  implementations, 
the  J10S  defines  a  conceptual  set  of  primitives 
for  which  detailed  software  interfaces  are 
described.  Only  this  approach  allows  application 
software  to  be  transportable  and  capable  of 
rendering  consistent  results. 

3.2  Pi-Bus  Structure 

The  J10S  categorizes  the  PI -Bus  routines  as 
fol lows: 

*  Master  PI -Bus  Interface  -  routines  and  data 
structure  definitions  used  for  transmitting 
messages  over  the  PI -Bus. 

*  Slave  PI -Bus  Interface  -  routines  and  data 
structure  definitions  used  for  receiving 
messages  from  the  PI -Bus. 

*  PI -Bus  Interrupt  Interface  -  routines 
which  describes  routines,  data  structures, 
and  protocol  for  servicing  PI -Bus  interrupts. 

*  Error  PI -Bus  Interface  -  routines  and  data 
structure  definitions  for  Pi-Bus  related 
error  handl ing. 

*  Conf igurat ion  and  Control  Interface  - 
routines  and  data  structure  definitions  for 
Pi-Bus  related  configuration  and  control 
processing. 

The  remainder  of  this  paragraph  gives  a  further 
description  of  each  category. 

3.2.1  Master  Pi-Bus  Interface. 

The  basic  data  structure  for  transmitting 
messages  is  the  Communication  Control  Block  (CCB). 
The  CCB  is  a  concept  used  by  al 1  the  J1AWG  PI -Bus 
vendors.  A  CCB  contains  the  PI -Bus  header  words 
for  the  message  to  be  sent,  identifies  the  data  to 
be  sent,  denotes  whether  an  interrupt  should  be 


generated  upon  transmission  of  the  message 
associated  with  the  CCB,  and  denotes  if  there  is 
another  CCB  "chained”  to  it.  PI -Bus  messages 
with/without  extended  headers  are  supported. 

The  interface  also  defines  a  data  structure 
called  the  logical  priority.  The  logical  priority 
is  be  used  for  the  interface  when  a  message  is 
transmitted  over  the  Pi-Bus. 

This  category  includes  routines  to  build 
CCBs,  modify  CCBs,  execute  CCBs,  abort  a  CCB, 
allow  a  CCB  chain  to  supercede  a  currently 
executing  CCB  chain,  and  set  the  logical  priority 
to  be  used  for  PI -Bus  transmissions. 

3.2.2  Slave  Pi-Bus  Interface 

There  are  two  basic  data  structures  defined 
in  the  Slave  Pi-Bus  Interface:  label  table  and 
message  report. 

The  label  table  is  a  concept  used  by  all  the 
J1AWG  PI -Bus  vendors  -  even  though  the  label  table 
entry  definitions  are  not  identical.  A  label 
table  entry  denotes  whether  the  label  is  active, 
whether  an  interrupt  should  occur  upon  successful 
reception  of  a  message  to  the  label,  where  the 
message  being  received  should  be  written  to  in 
memory,  whether  the  buffer  is  busy,  whether  double 
buffering  is  enabled  and  if  so,  the  address  of  the 
alternate  buffer,  and  the  maximum  size  message 
allowed  to  be  received  by  the  label. 

The  message  report  is  returned  to  the  PI -Bus 
interrupt  handler  when  a  received  message  is 
"popped"  from  the  received  message  queue.  Most 
J1AWG  vendors  refer  to  the  received  message  queue 
as  the  Slave  Receive  List.  The  message  report 
contains  the  PI -Bus  header  words  (including 
extended  header  words  for  messages  with  extended 
headers)  and  a  copy  of  the  associated  label  table 
entry  for  label  messages. 

This  category  contains  routines  to  set  the 
maximum  label  value  for  the  label  table,  to 
initialize  the  label  table,  and  to  read  and  write 
label  table  entries. 

3.2.3  PI -Bus  Interrupt  Interface 

The  basic  data  structure  defined  by  the 
PI -Bus  Interrupt  Interface  is  the  interrupt  queue. 
The  interrupt  queue  logically  contains  a  record 
for  each  PI -Bus  interrupt  that  has  not  been 
"popped"  by  application  code.  Each  interrupt 
queue  record  contains  the  cause  of  the  Interrupt: 
no  service  required,  master  error,  slave  error, 
message  received,  transfer  complete,  or  self-test 
complete.  Based  on  the  cause,  the  record  contains 
pertinent  information  needed  by  the  application 
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software  to  service  the  interrupt: 

*  no  service  -  ignore 

*  master  error  -  master  error  report 

*  slave  error  -  slave  error  report 

*  message  received  -  message  report 

*  transfer  complete  -  pointer  to  CCB  processed 

*  self-test  complete  -  status  of  self-test. 

This  category  contains  routines  to  determine 
the  current  PI -Bus  status  (as  defined  in  the 
Configuration  and  Control  Interface  category),  and 
to  pop  entries  from  the  interrupt  queue.  In 
addition,  there  is  a  routine  which  is  always 
called  by  the  PI -Bus  interrupt  handler  to  allow 
the  JIOS  to  perform  any  special  activities  that  It 
may  need  to  perform. 

3.2.4  Error  PI -Bus  Interface 

The  Error  PI -Bus  Interface  defines  the  Master 
and  Slave  Error  Report  data  structures  and 
includes  a  routine  to  invoke  JIOS  self-test  of  Its 
PI -Bus  features. 

3.2.5  Conf igurat ion  and  Control  Interface 

The  basic  data  structure  defined  by  the 
Configuration  and  Control  Interface  category  is 
the  PI -Bus  status  word. 

This  category  contains  routines  for  reading 
the  Pi-Bus  status,  denoting  whether  the  module 
will  be  suspendable  when  it  is  a  PI -Bus  Slave, 
setting  and  resetting  the  module  as  busy  with 
respect  to  the  PI -Bus,  enabling  and  disabling  the 
PI -Bus  logical  identifiers,  reading  the 
configuration  image,  reading  the  multicast 
acknowledge  registers,  writing  vie  interval  A  and 
B  timers,  writing  the  vie  priority  register, 
enabling  and  disabling  the  Pi-Bus  transceivers, 
resetting  the  module's  PI -Bus  Interface,  switching 
the  active  PI -Bus  channel,  and  reading  and  setting 
the  PI -Bus  system  time. 

4.0  The  I  OB  IDS  DEMONSTRATION 

Despite  the  path  to  commonality  that  JIOS 
offers,  this  approach  is  both  unconventional  and, 
admittedly  for  reasons  that  will  follow,  not  the 
best  technical  path.  As  a  consequence,  at  least 
three  important  questions  remain  about  the 
feasibility  of  the  JIOS. 

The  first  area  of  concern  Is  performance. 
Adding  an  additional  software  layer  will  cost 
execution  speed,  but  there  Is  no  simple  way  to 
estimate  this  loss.  Some  argue.  In  support  of 
JIOS,  that  since  current  bus  driver  software  is 
written  In  Ada  and  provides  similar  functionality 
as  the  JIOS,  the  loss  will  be  minimal. 


Another  area  of  concern  Is  program  size.  The 
requirement  that  the  JIOS  be  an  Integral  part  of 
the  module  architecture  means,  in  practice,  that 
any  software  the  vendor  must  use  for  JIOS  will  be 
stored  in  on-the-module's  Start-Up  Read-Only 
Memory  (SUROM).  Since  data  processor  module  real 
estate  Is  very  limited,  a  smal i  SUROM  is 
preferred.  CAP- 16  currently  requires  a  32  thousand 
16-bit  word  SUROM,  but  this  must  contain  the 
bootloader,  parts  of  the  executive,  diagnostic 
code,  and  perhaps  other  vendor  code,  as  well  as 
the  JIOS. 

A  third  area  of  concern  is  information 
security.  The  interaction  of  the  Input /output 
software  with  the  operational  software  raises 
security  Issues. 

A  demonstration  program  has  been  established  to 
answer  these  questions.  The  demonstration  will  use 
the  CAP- 16  gate  level  simulation  models  produced 
as  part  of  the  ZyCad-Air  Force  program. 
Demonstration  of  Avionic  Module  Exchangeability 
via  Simulation  (DAMES).  The  CAP- 1 6  subcontractors 
involved  are  IBM,  Texas  Instruments,  and  Unisys. 

As  part  of  the  demonstration  program,  a  subset 
of  PI -Bus  functionality  of  the  JIOS  will  be 
Implemented,  as  a  prototype,  for  the  IBM  and  T1 
Cap- 16  models  simulated  in  the  DAMES  program.  An 
IOBIDS  executive  will  be  developed  which  makes 
calls  to  PI -Bus  support  routines.  Two  versions  of 
the  PI -Bus  routines  will  be  Implemented.  One 
makes  calls  to  the  JIOS.  The  other  uses  a 
conventional  approach  based  on  existing  PI -Bus 
driver  software.  Based  on  the  JIOS  prototypes, 
both  performance  and  program  size  estimates  will 
be  made.  By  comparing  the  timings  of  the  JIOS 
and  conventional  Implementation,  any  performance 
degradation  incurred  by  using  the  JIOS  will  be 
estimated.  The  sizes  for  the  demonstration  JIOS 
will  be  used  to  estimate  the  memory  size  for  a 
complete  JIOS  Implementation.  The  security 
question  will  not  be  addressed  in  the 
demonstration.  Based  on  these  estimates  a  decision 
will  be  made  as  to  whether  the  JIOS  is  an 
acceptable  approach  for  the  J1AWG. 

5.0  JIOS  DRAWBACKS 

As  alluded  to  above,  one  of  the  original 
goals  of  JIOS  was  to  provide  a  software  interface 
that  could  eventually  be  implemented  entirely  in 
hardware.  However,  as  already  noted,  to  avoid 
software  changes  for  systems  already  using  JIOS,  a 
small  part  of  JIOS  must  always  be  present.  This 
part  will  be  the  entry  point  to  JIOS  calls,  which 
translates  a  call  to  the  appropriate  XIO  call. 

There  are  two  other  areas  which  have  been 
discovered  In  defining  the  JIOS  which  should  not 
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be  considered  candidates  for  hardware 
implementation.  First,  there  are  many  data 
structures  assumed  by  the  JIOS  (e.g.,  Pi-Bus  Label 
Table)  which  must  be  allocated  from  the  JIOS  user 
memory,  but  must  be  Initialized  through  JIOS 
calls.  Thus,  these  calls  do  not  lend  themselves 
to  a  direct  hardware  Implementation.  This  is 
required  since  the  same  logical  data  structure  has 
different  bit-by-bit  definitions  for  the  various 
vendor  Implementations.  Clearly,  a  hardware 
implementation  would  allow  user  direct  access  to 
these  data  structures. 

Another  JIOS  drawback  Is  that  the  details  of 
the  vendor  Interrupt  structures  had  to  be  hidden 
because  of  grossly  dissimilar  implementations.  It 
Is  not  obvious  that  the  current  JIOS  design,  a 
logical  queue,  leads  in  a  natural  way  to  a 
hardware  Implementation.  For  the  PI -Bus,  for 
example,  there  are  several  reasons  an  interrupt 
can  occur  (e.g.,  message  received,  message 
transferred,  self-test  complete,  error).  In  order 
to  accommodate  the  existing  designs,  the  JIOS 
Interface  logically  queues  all  unserviced 
Interrupts.  When  the  JIOS  user  "pops”  an 
unserviced  Interrupt,  the  user  has  no  control  over 
which  interrupt  is  popped.  A  hardware 
Implementation  would  allow  this  capability. 

Beyond,  these  two  concerns,  the  JIOS  Interface 
appears  to  be  a  good  baseline  for  future  XIO 
definitions . 


6.0  SUMMARY  AND  CONCLUSIONS 

The  I0BIDS,  and  the  JIOS  it  defines,  Is  the 
product  of  three  Government  services,  five  prime 
contractors,  and  four  computer  subcontractors.  The 
goal  of  the  JIOS  Is  to  offer  current  MIL-STD-I750A 
data  processor  designer,  despite  I/O  policies 
inconsistent  with  CAP- 1 6  requirements,  a  method  of 
compliance  which  wl i i  not  cause  substantial 
hardware  redesigns.  The  JIOS  standard  will 
eventually  mature  so  that  most  of  the  JIOS 
will  become  a  pure  ISA-level  hardware  standard, 
effectively  defining  a  new  set  of  user  defined 
XIOs. 

The  JIOS  Is  a  unique  approach  which  carries 
with  it  technical  risk  associated  with  performance 
and  program  size.  The  demonstration  will  provide 
data  on  these  areas  before  the  I  OB  IDS  approach  Is 
Imposed  contractually. 

Tri -service  hardware  commonality  has  proven 
to  be  a  technically  challenging  goal  to  pursue. 

The  cost  and  schedule  benefits  of  achieving  this 
goal,  though,  are  so  potentially  large  that  the 
chal ienge  should  prove  to  be  worth  the  time  and 
dollars  spent  in  meeting  It.  I OB  IDS  Is  one  of  many 
components  needed  to  achieve  this  commonality. 
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